[00:01.910 --> 00:08.910]  All right, so this is the worst mobile apps, and it's just a review of the last several years of
[00:08.910 --> 00:15.190]  my work auditing the security of mobile apps in a very simple way. So I'm a teacher at City College
[00:15.190 --> 00:22.330]  San Francisco, and I founded this company called InfoSec Decoded, and I do a lot of these classes,
[00:22.330 --> 00:29.650]  and I'm not very advanced. I do beginning classes and simple things. The really complicated stuff
[00:29.650 --> 00:37.670]  is usually beyond my classes. So mobile apps are a natural place to start because security
[00:37.670 --> 00:42.810]  is terrible. Mobile apps... finding vulnerabilities in mobile apps is like taking a time machine back
[00:42.810 --> 00:49.190]  to the early 90s when people didn't know anything about security. And so I did a lot of Android
[00:49.190 --> 00:56.210]  auditing because it's very easy on Android, and it was very difficult on iOS until check rain.
[00:56.210 --> 01:02.590]  So Android I did over the last several years, and iOS I've only done for about the last six months.
[01:02.610 --> 01:09.190]  And I discovered that it is true what I had heard, that iOS apps are just as bad as Android apps.
[01:09.190 --> 01:14.790]  Now the operating system is a little more secure, and the coding language is harder to reverse
[01:14.790 --> 01:22.510]  engineer because it really is executable code compiled from C instead of partially compiled
[01:22.510 --> 01:29.170]  from Java. But the end result is it's painfully obvious that the standards of most app developers
[01:29.170 --> 01:36.150]  are extremely low, and that the management does not review the security of apps they purchase
[01:36.150 --> 01:43.550]  from third-party developers, not even for the simplest flaws. So OWASP has a nice mobile top 10
[01:43.550 --> 01:49.290]  showing the vulnerabilities here. And when I did Android apps, I typically found the ones
[01:49.290 --> 01:55.490]  marked 8 and 9 here, where you can easily see the source code and find vulnerabilities. That is not
[01:55.490 --> 02:01.670]  so easy to do on iOS, but the other ones are extremely common, like insecure data storage
[02:01.670 --> 02:08.090]  and insecure communication and insufficient cryptography. Those are all extremely common.
[02:08.650 --> 02:13.670]  So first, I'll just start with the headline, the worst apps I found.
[02:14.710 --> 02:19.870]  The worst app in the world is probably this one, because not only is it incredibly
[02:19.870 --> 02:25.930]  mind-bogglingly insecure, it's still in common use for an important purpose. This company, Equity
[02:25.930 --> 02:32.310]  Pandit, is apparently a widely respected company in India and even has passed some kind of certification
[02:32.310 --> 02:39.210]  for at least functionality. And their app has the worst API I've ever encountered that's still in use.
[02:39.210 --> 02:44.970]  If you go to their API, not only does it log you in with plain text transmission over the internet
[02:45.510 --> 02:50.930]  and then store your password in plain text locally. Beyond that, if you try to log in
[02:50.930 --> 02:58.430]  with an incorrect password, the logic is shown in the top here. It doesn't send your username
[02:58.430 --> 03:03.630]  and password to the server to authenticate you. It sends your email address to the server and
[03:03.630 --> 03:10.130]  then it sends the correct password down to the phone, and then it compares the password you typed
[03:10.130 --> 03:16.250]  to the password on the phone. And it puts both of them in a log. So at the top in that command line
[03:16.250 --> 03:23.790]  window, you see two passwords, capital P-S-S-W-0-R-D, and then one that's just a lot of A's and 2's.
[03:23.790 --> 03:29.110]  The A's and 2's are a wrong password I typed in, and it sends me the right password. So I gave my
[03:29.110 --> 03:34.390]  students homework to just steal my password from my account on their server, and anybody can get
[03:34.390 --> 03:39.210]  anybody's password at any time. And I told them years ago, and I've been giving it for homework
[03:39.210 --> 03:46.610]  and using it in classes all over the world, and they just don't care. That is amazing to me.
[03:46.610 --> 03:51.110]  That a company, especially a financial company, can just hand out all the passwords of everybody
[03:51.110 --> 03:58.250]  all the time, and nobody cares, but it's still going on. And this one here was almost as bad.
[03:58.250 --> 04:02.770]  The only thing better about it is they actually fixed it when I told them. The University of Houston
[04:02.770 --> 04:08.590]  had an alumni app, and so I installed it and played with it. And the first thing it does before you log
[04:08.590 --> 04:14.630]  in is it lets you search for yourself on the list of alumni. And when you do that, you'll see here
[04:14.630 --> 04:20.750]  in the top line, it sends a request with the first letter or two of a username up to the server, which
[04:20.750 --> 04:29.050]  is 326 bytes in the length column, and then the reply is 351 kilobytes. Every time anybody
[04:29.050 --> 04:35.890]  searches for a user in the app, before you log in, it downloads the entire database of every user,
[04:35.890 --> 04:44.790]  credit card numbers, account numbers, passwords, email addresses, down onto the phone, and it does
[04:44.790 --> 04:50.730]  all that with broken encryption. So you get, again, get exposure to the entire database. But when I
[04:50.730 --> 04:54.670]  told them, they actually took down the app and made a revised version that no longer has these
[04:54.670 --> 05:00.150]  flaws. But when I showed this to students, some of my students said this, in fact, is something they
[05:00.150 --> 05:04.610]  tell people to do, put everything on the phone so it will have fast response, even if the network
[05:04.610 --> 05:13.310]  is slow. But it is surprisingly bad. So not every app is that bad, but a large portion of apps,
[05:13.310 --> 05:18.950]  like 10 or 15 percent, make extremely elementary flaws so simple that I can catch them. So over
[05:18.950 --> 05:23.870]  the last several years, I've done a lot of Android apps. I started by doing the top 10 banks,
[05:23.870 --> 05:28.210]  insurance companies, and stockbrokers, and essentially all of them are vulnerable to
[05:28.210 --> 05:33.530]  code modification. So you can see the source code, you can modify the code, you can make a modified
[05:33.530 --> 05:38.350]  app and run it, and they don't detect that it's modified, and they don't detect that it's an
[05:40.050 --> 05:44.130]  unauthorized app when it connects to the server, both of which would be pretty easy to do,
[05:44.130 --> 05:50.190]  but they just don't bother. And some of them make other errors, like using insecure encryption and
[05:50.190 --> 05:56.230]  such. But the fundamental reason why this is so easy to do on Android is the language it's in.
[05:56.230 --> 06:04.230]  So here's TD Ameritrade. If you log in here, it will put the password in the log. This is in the
[06:04.230 --> 06:09.050]  syslog on the app, and in older versions of Android, this was visible to every app on the device.
[06:09.050 --> 06:12.870]  That's not true of later versions of Android, but still, it's not an appropriate place
[06:12.870 --> 06:18.050]  to put secrets like a password. In fact, a best practice is to turn off all logging
[06:18.050 --> 06:23.810]  in the distribution version of your app. Logging should only be there for your test versions in
[06:23.810 --> 06:29.610]  production. So Mayo Clinic Medical Transport has the other issue of hard-coded credentials.
[06:29.610 --> 06:34.270]  There's a password needed to see this app, and the producer makes half a dozen apps built the
[06:34.270 --> 06:40.350]  same way. And you can just see the source code. You can download the code from the phone and grep
[06:40.350 --> 06:45.730]  for the word password and just find the top secret password. And I notified him, and he told
[06:45.730 --> 06:51.170]  me to just get lost. My notifications are spam. I'm just irritating him. So I appreciate it when
[06:51.170 --> 06:55.590]  people give me a response like that, because that's volunteering to be homework. So anyway,
[06:56.130 --> 07:04.370]  another very common flaw in both Android and iOS is that they break TLS. They perform an HTTPS
[07:04.370 --> 07:09.470]  handshake, and then they don't verify the certificate with a trusted third-party provider.
[07:09.470 --> 07:14.970]  So you can give them a fake certificate, and they'll fall for it. This, in fact, has led to
[07:14.970 --> 07:20.570]  some punishments from the Federal Trade Commission to Fandango and Credit Karma. If you had some
[07:20.570 --> 07:26.290]  standard boilerplate statement in your terms of service that we take reasonable security measures,
[07:26.290 --> 07:32.550]  this behavior, breaking TLS, was considered insufficient to comply with that promise.
[07:32.930 --> 07:37.810]  So then I gave some talks before about password storage on the phone.
[07:38.830 --> 07:44.370]  An enormous number of apps remember who you are by storing your password locally on the phone,
[07:44.370 --> 07:51.610]  which is very strange. So Target Australia had an Android app that does the right thing,
[07:51.610 --> 07:57.310]  what websites would do. It puts a random cookie on your machine. But for some reason, a large
[07:57.310 --> 08:02.510]  number of web apps just store your password locally, which is a miserable thing to do,
[08:02.510 --> 08:08.230]  and that's what Staples does. It puts a thing called encrypted password on your phone,
[08:08.230 --> 08:13.610]  and that is a very strange thing to do. And in fact, you know, if you look at best practices,
[08:13.610 --> 08:18.190]  they say don't store a password on the phone at all. If you're going to do it, there's an Android
[08:18.190 --> 08:23.630]  keychain to put it in. There's public key encryption you could use. But what they almost
[08:23.630 --> 08:29.850]  all do, if they don't store it in plain text, is they store it with private key encryption,
[08:29.850 --> 08:34.870]  and then they try to hide the key on the phone. So you can easily detect the flaws here.
[08:35.810 --> 08:40.890]  Anyway, so it's easy to see that they're using... here you can tell they're using
[08:40.890 --> 08:46.730]  electronic codebook encryption. So if you give it a password that's 32 A's in a row,
[08:46.730 --> 08:52.390]  you get encrypted data with a repeating block shown in the lower middle here. And that shows
[08:52.390 --> 08:58.190]  that an identical block of input turns into an identical block of output, which is another very
[08:58.190 --> 09:06.230]  fundamental encryption error. So anyway, they construct the password by using things like the
[09:06.230 --> 09:11.810]  username, and the name of the app, and so on. And you can just read their source code and see how
[09:11.810 --> 09:16.990]  they build the password. Here they take the brand, device, model, serial number, and the name of the
[09:16.990 --> 09:25.150]  package, and combine that to construct the key. So I can easily write a reversing code that will
[09:25.150 --> 09:31.230]  extract the key from that so-called encrypted password. Anyway, so I notified Staples and made
[09:31.230 --> 09:37.170]  videos of them and all that. But that's the game. Their fix was to just detect a rooted device,
[09:37.170 --> 09:42.850]  which is something. It's a step in the right direction. Anyway, a lot of apps store local
[09:42.850 --> 09:48.230]  plain text, Ace Hardware, and McDonald's, and so on. They just store the password with no encryption
[09:48.230 --> 09:53.610]  at all on the phone. A bunch of them use plain text login with unencrypted traffic over the
[09:53.610 --> 09:59.450]  internet. And you can catch them here. And then a lot of them break SSL, as I mentioned. Here's
[09:59.450 --> 10:04.970]  one. I first found this, I was excited, thinking I'd found a flaw in Amazon. But this is just a
[10:04.970 --> 10:11.350]  flaw in a third-party app that tracks Amazon prices. So that's a review of work I've done
[10:11.350 --> 10:17.630]  years ago, showing the kind of problems you have with Android apps. And so let me skip over a few
[10:17.630 --> 10:24.830]  more of these. These are things I've talked about before. Many, many big companies do these common
[10:26.010 --> 10:31.530]  app mistakes. And I never really knew how bad it was on iOS, because since there wasn't a good
[10:31.530 --> 10:38.710]  jailbreak available for iOS, I couldn't really look inside the file system in a modern version
[10:38.710 --> 10:45.230]  of iOS and see what was happening. So I was gradually moving forward in the world of security
[10:45.230 --> 10:50.510]  and trying to move into more advanced things. And then I saw this talk by Joe McCrae. Joe McCrae
[10:50.510 --> 10:56.470]  is wonderful. He's doing the same thing I'm doing. He's trying to show that a relatively normal person
[10:56.470 --> 11:01.370]  can figure out how to do this. And he made this talk called Exploit Development for Mere Mortals.
[11:01.370 --> 11:05.790]  And I looked at that talk, and it was wonderful, because I thought exploit development was just
[11:05.790 --> 11:10.150]  mind-boggling and complicated, and I could never figure it out, and my students could never figure
[11:10.150 --> 11:16.410]  it out. And Joe convinced me that it's not that hard. He explains it in simple terms and shows
[11:16.410 --> 11:21.490]  you how to use the basic tools like OliDebug, and I said, well, maybe I could do it after all.
[11:21.490 --> 11:26.290]  And then Georgia Weidman wrote this book, and the book has a lot of introductory stuff,
[11:26.290 --> 11:30.250]  but it has an appendix where you would develop a simple buffer overflow exploit,
[11:30.250 --> 11:35.890]  and that was the first document that wrote I could do this in terms I could really follow,
[11:35.890 --> 11:39.490]  and it really worked. So then I was able to start teaching exploit development.
[11:39.490 --> 11:43.330]  So I wrote this class where we go through the shellcoder's handbook and we develop
[11:43.330 --> 11:47.950]  buffer overflow exploits and other things like format string exploits.
[11:48.390 --> 11:54.070]  And that was very exciting to me, and it attracted a bunch of new, more advanced students,
[11:54.070 --> 11:59.010]  people who had never been interested in taking college courses in ordinary ethical hacking,
[11:59.010 --> 12:05.510]  were drawn to this class. And in particular, this guy, Axiom X, came to the class. He had
[12:05.510 --> 12:10.950]  been a developer, and he'd never done hacking or attack before, but he heard about this class
[12:10.950 --> 12:16.110]  and came and took it, and so immediately he raced through everything I knew and everything in my
[12:16.110 --> 12:22.790]  book, and he rushed into iOS hacking, because he was a real expert on iOS, and he immediately found
[12:22.790 --> 12:28.330]  the checkring vulnerability, which makes almost up to, I think, two versions back now, made all
[12:28.330 --> 12:33.390]  these modern versions of iOS vulnerable, and it was a flaw in a hardware module that can't be
[12:33.390 --> 12:38.350]  updated without a replacement of the hardware. So suddenly, because of him and the team that
[12:38.350 --> 12:43.950]  joined him to make the checkring exploits, we could now get into the system of modern iPhones,
[12:43.950 --> 12:50.290]  and that was fun. So I immediately got a couple jailbroken phones. He loaned me a couple,
[12:50.290 --> 12:57.670]  and I, over the January and December, six months ago or seven months ago, I spent all my time
[12:57.670 --> 13:02.990]  auditing iPhone apps. I audited a few hundred iPhone apps, and I found all the same problems
[13:02.990 --> 13:07.830]  with iPhone apps. Here's the Blue Cross app, storing passwords locally on the phone without
[13:07.830 --> 13:14.930]  any encryption. Here's Blue Shield failing to validate TLS certificates, so it will just believe
[13:15.250 --> 13:20.350]  a fake certificate from a fake certificate provider. Here's West Point, transmitting
[13:20.350 --> 13:25.870]  passwords without no encryption at all, plain text over the internet, a West Point athletic app.
[13:25.870 --> 13:32.450]  Here's an Air Force app doing the same thing. Then there's Zillow, which stores a local copy
[13:32.450 --> 13:41.690]  of the passwords in a cache insecurely. Here's StockOptions, a stock app that breaks TLS
[13:41.690 --> 13:48.370]  encryption and stores things locally and sends plain text transmissions over the internet.
[13:49.310 --> 13:54.090]  And I was surprised by this one when I found these apps that send plain text data over the
[13:54.090 --> 13:58.190]  internet, because I thought that was not possible anymore, because I saw a news article saying
[13:58.190 --> 14:04.510]  years ago Apple has updated their application policy so you can't use insecure network
[14:04.510 --> 14:09.190]  transmissions. But I went and looked, and this is the article. There is this thing called app
[14:09.190 --> 14:15.790]  transport security, but you don't have to use it. You only get app transport security if you turn it
[14:15.790 --> 14:22.830]  on or if you are targeting recent versions of iOS. So older apps or apps that turn it off don't have
[14:22.830 --> 14:27.870]  it. So you can continue to have iPhone apps that send unencrypted sensitive data over the internet,
[14:27.870 --> 14:34.230]  which surprised me. I had believed that Apple was more secure than that, but it's not so,
[14:34.230 --> 14:40.230]  and it certainly is not so in practice. So then I tried other apps. I tried My City College app,
[14:40.230 --> 14:45.170]  and I found that the entire product line, about half of their products, were all insecure. They
[14:45.170 --> 14:50.310]  all used broken encryption, breaking TLS, and one of them uses no encryption at all. It appears that
[14:50.310 --> 14:54.730]  this company has swallowed up some other app companies, and they've inherited some products
[14:54.730 --> 14:59.070]  that are insecure. And I told them about this. All these vulnerabilities, by the way, I've
[14:59.070 --> 15:04.330]  disclosed many months ago. So I think they've been fixed if they're ever going to be fixed.
[15:05.730 --> 15:10.050]  And to be fair, I should say I've done a lot of vulnerability disclosure like this. This is white
[15:10.050 --> 15:15.170]  hatting, which is generally considered a waste of your time and an amateur move where you try to
[15:15.170 --> 15:21.250]  tell people about their problems when they have not come to you to ask for an audit. And it used
[15:21.250 --> 15:26.830]  to be that only 2% of them would ever fix it. And now it's up to maybe 10% of them fix it. And
[15:26.830 --> 15:31.130]  some of them even say thank you and promise to send me stuff and then never send me the stuff.
[15:31.250 --> 15:36.570]  But nobody tried to get me fired or start a lawsuit or anything this time. So I think
[15:36.570 --> 15:45.010]  the US government bug bounties have begun to raise awareness so that more companies don't just freak
[15:45.010 --> 15:50.150]  out and decide that you're a criminal when you report a vulnerability. And it's getting moving
[15:50.150 --> 15:55.590]  from 2% up to maybe 10% of them that actually care. Very few of them are actually ready to do
[15:55.590 --> 16:01.450]  anything about a vulnerability or fix it. But I think they're more it's becoming more common that
[16:01.450 --> 16:06.170]  they will at least admit that it is possible that they have a security flaw. And that in principle,
[16:06.170 --> 16:11.390]  they should do something about it instead of just shooting the messenger. So it's gradually improving.
[16:12.110 --> 16:18.450]  And I tried these chains of financial apps. I did a lot of bank apps. And I found this whole
[16:18.450 --> 16:24.610]  line of apps from Jack Henry that puts your password in the log, which is unsafe. And there's
[16:24.690 --> 16:31.070]  a whole series of banks using it. And then I found another financial app company. And again, they had
[16:31.070 --> 16:34.870]  the same thing, but a different structure. They also put your password in the log every time you
[16:34.870 --> 16:41.670]  logged in. So I notified their customers and the main provider that they needed to fix that. I
[16:41.670 --> 16:45.990]  don't know if they care. But I was surprised they have whole vulnerable product lines. And you would
[16:45.990 --> 16:51.330]  think at least that a developer that's making a whole product line would have some security
[16:51.330 --> 16:56.970]  auditing. But obviously, they don't. And their customers don't. So you can just sell broken junk
[16:56.970 --> 17:04.950]  forever. And nobody will catch you for a long time. So I've got a hacking mobile devices class
[17:04.950 --> 17:10.610]  where we've been doing this. And now we're moving into iOS in addition to Android. And I made a
[17:10.610 --> 17:15.390]  cryptography class trying to improve people's awareness of cryptography. So hopefully, they
[17:15.390 --> 17:20.910]  won't make so many fundamental cryptography mistakes. And you know, the basic bottom line
[17:20.910 --> 17:24.810]  here is nothing that exciting. You should be auditing your apps. You should have managers
[17:25.310 --> 17:29.530]  that ask the simple questions. And they don't have to be very technical. They need to say,
[17:29.530 --> 17:35.250]  did you collect data from the user? Where did you put it? Did you encrypt it? Where did you put the
[17:35.250 --> 17:41.010]  key? How did you transmit it? And you should have nice, simple, clear answers to those questions.
[17:41.010 --> 17:48.890]  And if you don't, then you shouldn't accept that app. So that's what I've got to tell you.
